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Abstract 


This document discusses procedural issues related to the 
extensibility of IETF protocols, including when it is reasonable to 
extend IETF protocols with little or no review, and when extensions 
or variations need to be reviewed by the IETF community. Experience 
has shown that extension of protocols without early IETF review can 
carry risk. The document also recommends that major extensions to or 
variations of IETF protocols only take place through normal IETF 
processes or in coordination with the IETF. 


This document is directed principally at other Standards Development 
Organizations (SDOs) and vendors considering requirements for 
extensions to IETF protocols. It does not modify formal IETF 
processes. 
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1. Introduction 


BCP 9 [RFC2026] is the current definition of the IETF standards 
track. This process applies not only to the initial definition of a 
protocol, but also to any subsequent updates, such that continued 
interoperability can be guaranteed. However, it is not always clear 
whether extensions to a protocol should be made within the IETF 
process, especially when they originate outside the IETF community. 
This document lays down guidelines and procedures for such 
extensions. 


When developing protocols, IETF Working Groups (WGs) typically 
include mechanisms whereby these protocols can be extended in the 
future. It is, of course, a good principle to design extensibility 
into protocols; a common definition of a successful protocol is one 
that becomes widely used in ways not originally anticipated. Well- 
designed extensibility mechanisms facilitate the evolution of 
protocols and help make it easier to roll out incremental changes in 
an interoperable fashion. At the same time, experience has shown 
that extensibility features should be limited to what is clearly 
necessary when the protocol is developed, and any later extensions 
should be done carefully and with a full understanding of the base 
protocol, existing implementations, and current operational practice. 
However, it is not the purpose of this document to describe the 
architectural principles of sound extensibility design. 
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When extensions to IETF protocols are made within the IETF, the 
normal IETF process is followed, including the normal processes for 
IETF-wide review and IESG approval. Extensions developed in this way 
should respect the same architectural principles and technical 
criteria as any other IETF work. 


In addition to the IETF itself, other Standards Development 
Organizations (SDOs), vendors, and technology fora may identify a 
requirement for an extension to an IETF protocol. The question 
addressed by this document is how such bodies should proceed. There 
are several possible scenarios: 


1. The requirement is straightforward and within the scope of 
whatever extension mechanism the base protocol includes. 


2. The requirement is, or may be, outside that scope, and: 
1. The IETF still has an active WG in the area; 
2. The IETF has no active WG, but has relevant expertise; 
3. The IETF no longer has a nucleus of relevant expertise. 


Especially in the latter three cases, there are technical risks in 
extension design, described in the next section. These risks are 

higher when extensions to IETF protocols are made outside the IETF 
and without consulting the IETF. 


This document is focused on appropriate procedures and practices to 
minimize the chance that extensions developed outside the IETF will 
encounter these risks and, therefore, become useless or, worse, 
damaging to interoperability. Architectural considerations are 


documented elsewhere. This document is directed principally at other 
SDOs and vendors considering requirements for extensions to IETF 
protocols. It does not modify formal IETF processes. 


The IETF claims no special position. Everything said here about IETF 
protocols would apply with equal force to protocols specified by any 
SDO. The IETF should follow whatever procedures another SDO lays 
down for extensions to its own protocols, if the IETF identifies a 
need for such an extension. 


2. Technical Risks in Extensions 


Extensions may be developed without full understanding of why the 
existing protocol was designed the way that it is -- e.g., what ideas 
were brought up during the original development and rejected because 
of some problem with them. Also, extensions could unintentionally 
negate some key function of the existing protocol (such as security 
or congestion control). Design choices can be made without analyzing 
their impact on the protocol as a whole, and basic underlying 
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KS 


architectural principles of the protocol can be violated. Also, 
there is a risk that mutually incompatible extensions may be 
developed independently. 


Of course, the IETF itself is not immune to such mistakes, suggesting 
a need for WGs to document their design decisions (including paths 
rejected) and some rationale for those decisions, for the benefit of 
both those within the IETF and those outside the IETF, perhaps years 
later. 


Documentation of non-IETF extensions can sometimes be hard to obtain, 
so assessing the quality of the specification, verifying 
interoperability, and verifying compatibility with other extensions 
(including past and future extensions) can be hard or impossible. 


A set of interrelated extensions to multiple protocols typically 
carries a greater danger of interoperability issues or 
incompatibilities than a simple extension. Consequently, it is 
important that such proposals receive earlier and more in-depth 
review than unitary extensions. 


All that can be said about extensions applies with equal or greater 
force to variations -- in fact, by definition, protocol variations 
damage interoperability. They must, therefore, be intensely 
scrutinized. An extension adds features and, if well designed, 
allows interoperability between old and new implementations. A 
variation modifies features in such a way that old and new 
implementations may not interoperate. Throughout this document, what 
is said about extensions also applies to variations. 


General Considerations 
1. The Importance of Interoperability 


According to its Mission Statement [RFC3935], the IETF produces high 
quality, relevant technical and engineering documents, including 
protocol standards. The mission statement goes on to say that the 
benefit of these standards to the Internet "is in interoperability - 
that multiple products implementing a standard are able to work 
together in order to deliver valuable functions to the Internet’s 
users". 


One consequence of this mission is that the IETF designs protocols 
for the single Internet. The IETF expects its protocols to work the 
same everywhere. Protocol extensions designed for limited 
environments may be reasonable provided that products with these 
extensions interoperate with products without the extensions. 
Extensions that break interoperability are unacceptable when products 


Bradner, et al. Best Current Practice [Page 4] 


RFC 4775 Procedures for Protocol Extensions December 2006 


with and without the extension are mixed. It is the IETF’s 
experience that this tends to happen on the Internet even when the 
original designers of the extension did not expect this to happen. 


Another consequence of this definition of interoperability is that 
the IETF values the ability to exchange one product implementing a 
protocol with another. The IETF often specifies mandatory-to- 
implement functionality as part of its protocols so that there is a 
core set of functionality sufficient for interoperability that all 
products implement. The IETF tries to avoid situations where 
protocols need to be profiled to specify which optional features are 
required for a given environment, because doing so harms 
interoperability on the Internet as a whole. 


The IETF, and in particular the IESG, will apply these considerations 
when evaluating protocol extensions proposed inside or outside the 
IETF. 


3.2. Registered Values and the Importance of IANA Assignments 


An extension is often likely to make use of additional values added 
to an existing IANA registry (in many cases, simply by adding a new 
"TLV" (type-length-value) field). It is essential that such new 
values are properly registered by the applicable procedures, 
including expert review where applicable (see BCP 26, [RFC2434]). 
Extensions may even need to create new IANA registries in some cases. 


Experience shows that the importance of this is often underestimated 
during extension design; designers sometimes assume that a new 
codepoint is theirs for the asking, or even simply for the taking. 
This is hazardous; it is far too likely that someone just taking a 
protocol value will find that the same value will later be formally 
assigned to another function, thus guaranteeing an interoperability 
problem. 


In many cases, IANA assignment requests trigger a thorough technical 
review of the proposal by a designated IETF expert reviewer. 
Requests are sometimes refused after such a review. Thus, extension 
designers must pay particular attention to any needed IANA 
assignments and to the applicable criteria. 


3.3. Significant Extensions Require Technical Review 


Some extensions may be considered minor (e.g., adding a 
straightforward new TLV to an application protocol, which will only 
impact a subset of hosts) and some may be considered major (e.g., 
adding a new IP option type, which will potentially impact every node 
on the Internet). This is essentially a matter of judgment. It 
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could be argued that anything requiring at most Expert Review in 
[RFC2434] is probably minor, and anything beyond that is major. 
However, even an apparently minor extension may have unforeseen 
consequences on interoperability. Thus, the distinction between 
major and minor is less important than ensuring that the right amount 


of technical review takes place in either case. In general, the 
expertise for such review lies within the same SDO that developed the 
original protocol. Therefore, the expertise for such review for IETF 


protocols lies within the IETF. 


There may sometimes be doubt whether a particular proposal is or is 
not truly a protocol extension. When in doubt, it is preferable to 
err on the side of additional review. However, it should be noted 
that if an ’extension’ only consists of registering a new value with 
IANA in a First Come First Served registry [RFC2434], this document 


is not intended to require formal IETF review. Informal review by 
experts may, nevertheless, be valuable. In other cases (Section 5), 
there is a well-specified procedure for extensions that should be 
followed. 


The only safe rule is that, even if an extension appears minor to the 
person proposing it, early review by subject matter experts is 
advisable. For protocols that have been developed in the IETF, the 
appropriate forum for such review is the IETF, either in the relevant 
WG or Area, or by individual IETF experts if no such WG exists. 


3.4. Quality and Consistency 


In order to be adequately reviewed by relevant experts, a proposed 
extension must be documented in a clear and well-written 
specification that IETF subject matter experts have access to and can 
review. Ideally, such a document would be published as an Internet 
Draft, using terminology and content that is sufficiently consistent 
with the unextended specification that these experts can readily 
identify the technical changes proposed at an early stage. 


3.5. The Role of Formal Liaisons 


The IETF has formal liaisons in place with a number of SDOs; 
documentation of the liaison process is in [RFC4052], [RFC4053], and 
[RFC4691]. These liaison channels should be used as relevant for 
discussing and reviewing extensions, as should informal communication 
at the engineering level (for example, experts from other SDOs are 
welcome to participate in IETF meetings and mailing lists). Where 
formal liaison does not exist, the point of contact in the IETF 
should be the Chairs of relevant WGs, the most appropriate Area 
Director, or, in case of doubt, the IESG as a whole. 
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4. 


Procedure for Review of Extensions 


In some cases, explicit provision is made in the relevant RFCs for 
extending individual IETF protocols. Nothing in this document 
overrides such procedures. Some such cases are mentioned in 
Section 5. 


There are several ways in which an extension to an IETF protocol can 
be considered for publication as an RFC: 


1. Extensions to IETF protocols developed within the IETF will be 
subject to the normal IETF process, exactly like new designs. It 
is not suggested that this is a panacea; appropriate cross- 
working-group and cross-area review is needed within the IETF to 
avoid oversights and mistakes. 


2. Extensions to IETF protocols discussed in an IRTF Research Group 
may well be the prelude to regular IETF discussion. However, a 
Research Group may desire to specify an experimental extension 
before the work is mature enough for IETF processing. In this 
case, the Research Group is required to involve appropriate IETF 
or IANA experts in their process to avoid oversights. 


3. Extensions to IETF protocols described in Independent Submissions 
to the RFC Editor are subject to IESG review, currently described 
in BCP 92 [RFC3932]. If appropriate, the IESG advises the RFC 
Editor that full IETF processing is needed, or that relevant IANA 
procedures need to be followed before publication can proceed. 
Note that Independent Submissions cannot be placed on the IETF 
Standards Track; they would need to enter full IETF processing. 


Where vendors or other SDOs identify a requirement for extending an 
IETF protocol, their first step should be to consider the scenarios 
listed in Section 1. If the requirement is straightforward and 
within the scope of a documented extension mechanism, the way is 
clear, and the documented mechanism must be followed. If these two 
conditions are not met, the next step should be to contact the 
relevant IETF Area Director to check whether there is an active WG in 
the area or, at least, relevant expertise available in the IETF. At 
this point, it will be possible to select the most appropriate of the 
above three routes. Regular IETF process is most likely to be 
suitable, assuming sufficient interest can be found in the IETF 
community. IRTF process is unlikely to be suitable unless there is a 
genuine research context for the proposed extension. 
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In the event that the IETF no longer has relevant expertise, there 
are still two choices to discuss with the Area Director: bring the 
work to the IETF (i.e., the IETF imports expertise) or reach mutual 
agreement to do the work elsewhere (i.e., the IETF explicitly exports 
change control). 


In the case of an SDO that identifies a requirement for a 
standardized extension, a standards development process within the 
IETF (while maintaining appropriate liaison) is strongly recommended 
in preference to publishing a non-IETF standard. Otherwise, the 
implementor community will be faced with a standard split into two or 
more parts in different styles, obtained from different sources, with 
no unitary control over quality, compatibility, interoperability, and 
intellectual property conditions. Note that, since participation in 
the IETF is open, there is no formality or restriction for 
participants in other SDOs choosing to work in the IETF as well. In 
some cases (see Section 5), the IETF has well-defined procedures for 
this in place. 


Naturally, SDOs can and do develop scenarios, requirements, and 
architectures based on IETF specifications. It is only actual 
protocol extensions and changes that need to go through the IETF 
process. However, there is large risk of wasted effort if 
significant investment is made in planning stages for use of IETF 
technology without early review and feedback from the IETF. Other 
SDOs are encouraged to communicate informally or formally with the 
IETF as early as possible, to avoid false starts. Early technical 
review in a collaborative spirit is of great value. Each SDO can 
"own" its ideas and discuss them in its own fora, but should start 
talking to the IETF experts about those ideas the moment the idea is 
well formulated. It is understood that close collaboration may be 
needed in order that the IETF experts correctly understand the 
systems architecture envisaged by the other SDO. This is much 
preferable to a situation where another SDO presents the IANA and the 
IETF with a ’fait accompli.’ 


Vendors that identify a requirement for an extension are strongly 
recommended to start informal discussion in the IETF and to publish a 
preliminary Internet Draft describing the requirements. This will 
allow the vendor, and the community, to evaluate whether there is 
community interest and whether there are any major or fundamental 
issues. However, in the case of a vendor that identifies a 
requirement for a proprietary extension that does not generate 
interest in the IETF (or IRTF) communities, an Independent Submission 
to the RFC Editor is strongly recommended in preference to publishing 
a proprietary document. Not only does this bring the draft to the 
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attention of the community, but it also ensures a minimum of review 
[RFC3932], and (if published as an RFC) makes the proprietary 
extension available to the whole community. 


If, despite these recommendations, a vendor or SDO does choose to 
publish its own specification for an extension to an IETF protocol, 
the following guidance applies: 


o Extensions to IETF protocols should be well, and publicly, 
documented, and reviewed at an early stage by the IETF community 
to be sure that the extension does not undermine basic assumptions 
and safeguards designed into the protocol (such as security 
functions) or its architectural integrity. 


o Vendors and other SDOs are formally requested to submit any such 
proposed publications for IETF review, and are invited to actively 
participate in the IETF process. Submission may be by an 
established liaison channel if it exists, or by direct 
communication with the relevant WG or the IESG. This should be 
done at an early stage, before a large investment of effort has 
taken place, in case basic problems are revealed. When there is a 
formal liaison in place between the other SDO and the IETF, the 
liaison channel should be used to ensure that review takes place, 
both by relevant experts and by established review teams or 
Directorates within the IETF. If there is no formal liaison, the 
other SDO or vendor should ask the IESG (or a relevant Area 
Director) to obtain such reviews. Note that general aspects such 
as security, internationalization, and management may need review, 
as well as the protocol as such. 


o In the case of extensions involving only routine IANA parameter 
assignments, for which there is an underlying IETF specification 
containing clear IANA Considerations, this request is satisfied as 
long as those considerations are satisfied (see [RFC2434]). 
Anything beyond this requires an explicit protocol review by 
experts within the IETF. 


o Note that, like IETF specifications, such proposed publications 
must include an IANA Considerations section to ensure that 
protocol parameter assignments that are needed to deploy 
extensions are not made until after a proposed extension has 
received adequate review, and then to ensure that IANA has precise 
guidance on how to make those assignments. 
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Some Specific Issues 


It is relatively common for MIB modules, which are all, in effect, 
extensions of the SMI data model, to be defined or extended outside 
the IETF. BCP 111 [RFC4181] offers detailed guidance for authors and 
reviewers. 


A number of protocols have foreseen experimental values for certain 
IANA parameters, so that experimental usages and extensions may be 
tested without need for a special parameter assignment. It must be 
stressed that such values are not intended for production use or as a 
way to evade the type of technical review described in this document. 
See [RFC3692] and [RFC4727]. 


RADIUS [RFC2865] is designed to carry attributes and allow definition 
of new attributes. But it is important that discussion of new 
attributes involve the IETF community of experts knowledgeable about 
the protocol’s architecture and existing usage in order to fully 
understand the implications of a proposed extension. Adding new 
attributes without such discussion creates a high risk of 
interoperability or functionality failure. For this reason among 
others, the IETF has an active RADIUS Extensions WG at the time of 
writing. 


There are certain documents that specify a change process for 
specific IETF protocols, such as: 

The SIP change process [RFC3427] 

The (G)MPLS change process [CHANGEPROC ] 


This document does not override such specific change processes. 
Intellectual Property 


All IETF documents fall under the IETF’s intellectual property rules, 
BCP 78 [RFC3978] and BCP 79 [RFC3979], as amended. In particular, 
there are restrictions on the production of derivative works, and 
there are rights that remain with the original authors. Anybody 
outside the IETF considering an extension based on an IETF document 
must bear these legal restrictions and rights in mind. 


Security Considerations 


An extension must not introduce new security risks without also 
providing an adequate counter-measure, and in particular it must not 
inadvertently defeat security measures in the unextended protocol. 
This aspect must always be considered during IETF review. 
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10. 


10. 


IANA Considerations 


The IETF requests IANA to pay attention to the requirements of this 
document when requested to make protocol parameter assignments for 
vendors or other SDOs, i.e., to respect the IANA Considerations of 
all RFCs that contain them, and the general considerations of BCP 26 
[RFC2434]. 
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